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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP) based on work 
originally done by the Special Mobile Group (SMG) in ETSI. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document defines the stage two description of the Subscriber Identity Module Application Programming 
Interface (SIM API) internal to the SIM. 

This stage two describes the functional capabihties and the information flow for the SIM API implemented on the Java 
Card 2.1 API specification [6]. 

The present document includes information applicable to network operators, service providers and SIM, server and 
database manufacturers. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TR 21.905: "Abbreviations and acronyms". 

[2] 3GPP TS 51.011: "Specification of the Subscriber Identity Module - Mobile Equipment (SIM - 

ME) interface". 

[3] 3GPP TS 1 1 . 14: "Specification of the SIM Application Toolkit for the Subscriber Identity Module 

- Mobile Equipment (SIM - ME) interface". 

[4] 3GPP TS 23.048: "Security Mechanisms for the SIM apphcation toolkit; Stage 2". 

[5] ISO/IEC 7816-3 (1997) " Identification cai'ds - Integrated circuit(s) cards with contacts. Part 3: 

Electronic signals and transmission protocols". 

[6] 3GPP TS 42.019: "Subscriber Identity Module Apphcation Programming Interface (SIM API); 

Service description; Stage 1". 

[7] SUN Java Card Specification "Java Card 2. 1 API Specification". 

[8] SUN Java Card Specification "Java Card 2.1 Runtime Environment Specification". 

[9] SUN Java Card Specification "Java Card 2.1 VM Architecture Specification". 

SUN Java Card Specifications can be downloaded at http://iava.sun.com/products/iavacard 

[10] ETSI TS 101 220 "Integrated Circuit Cards (ICC); ETSI numbering system for 

telecommunication; Application providers (AID)". 

[II] 3GPP TS 23.040: "Technical reahzation of the Short Message Service (SMS)" 

[12] ISO/IEC 7816-6 (1995): "Identification cards - Integrated circuit(s) cards with contacts. Part 6 

Inter-industry data elements". 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Applet : An Applet is an application built up using a number of classes which will run under the control of the Java 
Card virtual machine. Applets designed for smart cards are sometimes referred to as Cardlets. 

Bytecode : Machine independent code generated by a Java compiler and executed by the Java interpreter. 

Class : The Class is a type that defines the implementation of a particular kind of object. A Class definition defines 
instance and class variables and methods. 

Framework : A framework defines a set of Application Programming Interface (API) classes for developing 
applications and for providing system services to those applications. 

GSM applet : The GSM application conforming to TS 51.01 1. It might be a Java Card applet or native application. 

Java : An object oriented programming language developed by Sun Microsystems designed to be platform 
independent. 

Method : A Method is a piece of executable code that can be invoked, possibly passing it certain values as arguments. 
Every Method definition belongs to some class. 

Object : The principal building block of object oriented programs. Each object is a programming unit consisting of 
data (variables) and functionality (methods) 

Package : A group of classes. Packages are declared when writing a Java Card program 

Toolkit applet : Applet loaded onto the SIM card seen by the Mobile as being part of the SIM Toolkit application and 
containing only the code necessary to run the application. These applets might be downloaded over the radio interface. 

Virtual Machine : The part of the Run-time environment responsible for interpreting the bytecode. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply, in addition to those listed in 
TR 21.905 [1]: 

AC Application Code 

AID Application Identifier 

APDU Application Protocol Data Unit 

API Application Programming Interface 

CAD Card Acceptance Device 

FFS For Further Study 

IFD Interface Device 

JCRE Java Card'""^ Run Time Environment 

JVM Java Virtual Machine 

ME Mobile Equipment 

MS Mobile Station 

SIM Subscriber Identity Module 

SE Sending Entity 

SMS-CB Short Message Service - Cell Broadcast 

SMS-PP Short Message Service - Point to Point 

USSD Unstructured Supplementary Services Data 

VM Virtual Machine 
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Description 



The present document describes an API for the GSM SIM. This API allows application programmers access to the 
functions and data described in TS 5 1 .01 1 [2] and TS 1 1 . 14 [3], such that SIM based services can be developed and 
loaded onto SIMs, quickly and, if necessarily, remotely, after the card has been issued. 

This API is an extension to the Java Card 2.1 API [7] based on the Java Card 2.1 Runtime Environment [8]. 



4.1 



GSIVI Java Card Architecture 



The over all architecture of the SIM Toolkit API based on Java Card 2.1 is: 
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Figure 1 : GSM Java Card Architecture 

SIM Toolkit Framework: this is the GSM Java Card runtime environment, it is composed of the JCRE, the Toolkit 
Registry, the Toolkit Handler and the File System. 

JCRE: this is specified in Java Card 2.1 Runtime Environment Specification [8] and is able to select any specific applet 
and transmit to it the process of its APDU. 

Toolkit Registry: this is handling all the registration information of the toolkit applets, and their link to the JCRE 

registry. 

Toolkit Handler: this is handling the availability of the system handler and the toolkit protocol (i.e. toolkit applet 
suspension). 

File System: this contains the card issuer file system, and handles the file access control and the applet file context. It is 
a JCRE owned object implementing the shareable interface sim.access.SIMView. 

Applets: these derive from javacard.framework.applet and provide the entry points : process, select, deselect, install as 
defined in the Java Card 2.1 Runtime Environment Specification [8]. 

Toolkit applets: these derive from javacard.framework.applet, so provide the same entry points, and implement the 
shareable interface sim.toolkit.Toolkitlnterface so that these applets can be triggered by an invocation of their 
processToolkit method. These applets' AID is defined in TS 101 220 [10]. 
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GSM Applet: this is the default applet as defined in Java Card 2.1 Runtime Environment Specification [8], it behaves 
as regular applet e.g. when another applet is selected via the SELECT AID APDU its deselect method is invoked. It's 
AID is defined in TS 101 220 [10]. This applet handles the TS 51.011[2] APDUs, CHVl/2, the GSM authentication 
algorithm and the subscriber file access control according to TS 5 1.0 11 [2]. 

Loader applet: this is handling the installation and uninstallation of the applets as specified in the applet loading 
specification TS 23.048 [4]. 

Shareable interface: this is defined in the Java Card 2. 1 specifications. 

4.2 Java Card Selection Mechanism 

The Java Card selection mechanism is defined in the Java Card Runtime Environment Specification [8]. 



5 GSIVI Framework 

5.1 Overview 

The GSM Framework consists of the GSM applet and the JCRE File System Object. 
The GSM Framework is based on two packages: 
- The GSM low level package [FFS] ; 

The sim.access package, which allows applets to access the GSM files. 

5.2 GSIVI file data access 

The following methods shall be offered by the API to card applets, to allow access to the GSM data: 

select Select a file without changing the current file of any other applet or of the subscriber session. At 

the invocation of the processToolkit method of a toolkit applet, the current file is the MF. The 
toolkit applet file context remains unchanged during the whole execution of the processToolkit 
method, the current record may be altered if the current file is a cyclic file and the content of the 
current file may be altered. This method returns the selected file information; 

status Read the file status information of the current DF; 

readBinary Read data bytes of the transparent EF currently selected by the applet; 

readRecord Read data bytes of the linear fixed or cyclic EF currently selected by the applet without changing 

the current record pointer of any other applet / subscriber. This method allows reading part of a 
record; 

updateBinary Modify data bytes of the transparent EF currently selected by the applet. The toolkit applet shall 
send the corresponding refresh ; 

updateRecord Modify data bytes of the linear fixed or cyclic EF currently selected by the applet. The current 

record pointer of other applets / subscriber shall not be changed in case of linear fixed EF but the 
record pointer of a cyclic EF shall be changed for all other applets / subscriber to the record 
number 1 . This method allows updating part of a record. The toolkit applet shall send the 
corresponding refresh ; 

seek Search a record of the linear fixed file currently selected by the applet starting with a given pattern. 

The current record pointer of any other applet or of the subscriber session shall not be changed; 

increase Increase the value of the last updated record of the cyclic EF currently selected. It becomes than 

record number 1 for every other applet and subscriber session. This method returns the increased 
value. The toolkit applet shall send the corresponding refresh; 

rehabilitate Rehabilitate the EF currently selected by the applet with effect for all other applets / subscriber. 

The toolkit applet shall send the corresponding refresh; 

invalidate Invalidate the EF currently selected by the applet with effect for all other applets / subscriber. The 

toolkit applet shall send the corresponding refresh. 

These methods are described in the sim.access. SIMView interface in Annex A. 
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5.3 



Access control 



The Access Control privileges of the applet are granted during installation according to the level of trust. When an 
applet requests access to GSM or operator specific files, the SIM Toolkit Framework checks if this access is allowed by 
examination of the file control information stored on the card. If access is granted the SIM Toolkit Framework will 
process the access request, if access is not granted, an exception will be thrown. 

[Contents and coding of the file(s) containing access control information will be defined in TS 51.011] 

5.4 GSM low Level API 

[FFS. This API allows the implementation of the GSM applet] 



6 SIM Toolkit Framework 

6.1 Overview 

The SIM API shall consist of APIs for TS 11 . 14 [3] (pro-active functions) and TS 51.011 [2] (transport functions). 
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Figure 2: SIM Toolkit Framework functional description 



ETSI 



3GPP TS 43.01 9 version 5.5.0 Release 5 1 ETSI TS 1 43 01 9 V5.5.0 (2002-1 2) 

In this model, the GSM data field structure is viewed as a series of data objects to the API. In the physical model of 
course, they may still be stored in elementary fields, but classes will access these data as part of the objects within those 

classes. 



6.2 Applet Triggering 



The application triggering portion of the SIM Toolkit Framework is responsible for the activation of toolkit applets, 
based on the APDU received by the GSM application. 
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Figure 3: toolkit applet triggering diagram 

The ME shall not be adversely affected by the presence of applets on the SIM card. For instance a syntactically correct 
Envelope shall not result in an error status word in case of a failure of an applet. The only application as seen by the ME 
is the SIM application. As a result, a toolkit applet may throw an exception, but this error will not be sent to the ME. 

The difference between a Java Card applet and a Toolkit applet is that the latter does not handle APDUs directly. It will 
handle higher level messages. Furthermore the execution of a method could span over multiple APDUs, in particular, 
the proactive protocol commands (Fetch, Terminal Response). 

As seen above, when the GSM applet is the selected application and when a toolkit applet is triggered the selectQ 
method of the toolkit applet shall not be launched since the toolkit applet itself is not really selected. 

Here after are the events that can trigger a toolkit applet : 

EVENT_FIRST_COMMAND_AFTER_SELECT 

Upon reception of the first command received by the GSM application after it has been selected or after the 
ATR if it is the default application, and before the Status Word of the processed command has been sent back 
by the GSM application, the toolkit framework shall trigger all the toolkit applets registered to this event. 

If the first command received by the GSM application is a toolkit applet triggering command (e.g. 
TERMINAL PROFILE), the toolkit applets registered on the 
EVENT_FIRST_COMMAND_AFTER_SELECT event shall be triggered first. 

The ProactiveHandler and the ProactiveResponseHandler shall not be available at the invocation of the 
processToolkit method of the toolkit applet on the EVENT_FIRST_COMMAND_AFTER_SELECT event. 

EVENT_PROFILE_DOWNLOAD 

Upon reception of the Terminal Profile command by the SIM, the SIM Toolkit Framework stores the ME 
profile and then triggers the registered toolkit applet which may want to change their registry. A toolkit applet 
may not be able to issue a proactive command. 

EVENT_MENU_SELECTION,EVENT_MENU_SELECTION_HELP_REQUEST 

A toolkit applet might be activated upon selection in the ME's menu by the user, or request help on this 
specific menu. 

In order to allow the user to choose in a menu, the SIM Toolkit Framework shall have previously issued a SET 
UP MENU proactive command. When a toolkit applet changes a menu entry of its registry object, the SIM 
Toolkit Framework shall dynamically update the menu stored in the ME during the current card session. The 
SIM Toolkit Framework shall use the data of the EFsume file when issuing the SET UP MENU proactive 
command. 



£75/ 



3GPP TS 43.01 9 version 5.5.0 Release 5 1 1 ETSI TS 1 43 01 9 V5.5.0 (2002-1 2) 

The positions of the toolkit applet menu entries in the item list, the requested item identifiers and the associated 
limits (e.g. maximum length of item text string) are defined at the loading of the toolkit applet. 

If at least one Menu id of a toolkit applet registers to EVENT_MENU_SELECTION_HELP_REQUEST, the 
SET UP MENU proactive command sent by the SIM Toolkit Framework shall indicate to the ME that help 
information is available unless all the menus entries that support help are disabled. A toolkit applet shall be 
triggered by the EVENT_MENU_SELECTION_HELP_REQUEST event only if the Menu Id corresponding 
to the Envelope Menu Selection Help Request received by the SIM Toolkit framework was registered with the 
helpSupported value set to true. 

EVENT_FORMA TTED_SMS_PP_ENV, EVENTJJNFORMA TTED_SMS_PP_ENV, 
EVENT_FORMATTED_SMS_PP_UPD,EVENT_UNFORMATTED_SMS_PP_UPD 

A toolkit applet can be activated upon the reception of a short message. 

There are two ways for a card to receive an SMS: via the Envelope SMS-PP Data Download or the Update 
Record EFsms instruction. 

The received SMS may be: 

- formatted according to TS 23.048[4] or an other protocol to identify explicitly the toolkit applet for which the 
message is sent; 

- unformatted or using a toolkit applet specific protocol the SIM Toolkit Framework will pass this data to all 
registered toolkit applets. 

The Short Message may be received as Concatenated Short Messages as defined in TS 23.040[I I]. It is the 
responsibility of the SIM Toolkit Framework to link single Short Messages together to re-assemble the original 
message before any further processing. The original Short Message shall be placed in one SMS TPDU TLV 
(with TP-UDL field coded on one octet) included in the EnvelopeHandler. The concatenation control headers 
used to re-assemble the short messages in the correct order shall not be present in the SMS TPDU. The TP- 
elements of the SMS TPDU and the Address (TS-Service-Centre- Address) shall correspond to the ones in the 
last received Short Message (independently of the Sequence number of Information-Element-Data). 

The minimum requirement for the SIM Toolkit Framework is to process a concatenated short message with the 
following properties: 

- the Information Element Identifier is equal to the 8 -bit reference number. 

- it contains uncompressed 8 bit data or uncompressed UCS2 data. 

EVENT_FORMATTED_SMS_PP_ENV 

This event is generated when a Short Message Point to Point (Single or Concatenated) is received by 
Envelope SMS-PP download APDU(s) and is formatted according to TS 23.048[4]. 

The SIM Toolkit Framework shall: 

verify the security of the Short Message as per TS 23 .048 [4]; 

trigger the toolkit applet registered with the corresponding TAR defined at applet loading; 

take the optional Application Data posted by the triggered toolkit applet if present; 

secure and send the response packet using SMS-DELIVER-REPORT or SMS-SUBMIT . 

When the toolkit applet is triggered, data shall be provided deciphered. 

EVENT_UNFORMATTED_SMS_PP_ENV 

This event is generated when a Short Message Point to Point (Single or Concatenated) is received by 
Envelope SMS-PP download APDU(s) and is unformatted. 

The registered toolkit applets will be triggered by this event and get the data transmitted in the Envelope APDU(s). 

Note: As a consequence of the EnvelopeResponseHandler availability rules specified in clause 6.6, only 
the first triggered toolkit applet is guaranteed to be able to send back a response. 

EVENT FORMATTED SMS PP UPD 
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This event is generated when a Short Message Point to Point (Single or Concatenated) is received by 
Update Record EFsms APDU(s) and is formatted according to TS 23.048 [4]. 

The SIM Toolkit Framework shall: 

update the EFsms file with the data received, it is then up to the receiving toolkit applet to 

change the SMS stored in the file (i.e. the toolkit applet need to have access to the EFsms 

file) 

verify the security of the Short Message as per TS 23 .048 [4]; 

convert the Update Record EFsms in the Envelope Handler TLV List; 

trigger the toolkit applet registered with the corresponding TAR defined at applet loading; 

When the toolkit applet is triggered, data shall be provided deciphered. 

The Update Record EFsms APDU shall be converted in a TLV list as defined below: 



UPDATE RECORD APDU 


nb 
bytes 


Handler TLV LIST 


size 


CLA, INS 


2 




1 


P1,P2 


2 


device Identity Absolute 
Record Number 


1 


P3 = 176 


1 




1 


status 


1 


device Identity Record 
Status 


1 


TS-SCA (RP-OA) 


<= 12 


Address 


Y 


SMSTPDU 


var 


SMSTPDU 


Y 


padding bytes 


var 




Y 



The EnvelopeHandler provided to the applet shall: 

return BTAG_SMS_PP_DOWNLOAD to the getEnvelopeTagO method call; 
return the Simple TLV list length to the getLength() method call; 
contain the Simple TLV list : 



EnvelopeHandler TLV List 



Device identities 



Address 



SMSTPDU 



The applet should use the fmdTLV() methods to get each Simple TLV. 

The Device Identity Simple TLV is used to store the information about the absolute record number in 
the EFsms file and the value of the EFsms record status byte, and formatted as defined below: 



Device identities Simple TLV 



Device identities tag 



length = 02 



Absolute Record Number 



Record Status 



With the absolute record number the toolkit applet can update EFsms in absolute mode to change the 
received SMS in a readable text. 

For Concatenated Short Message the Absolute Record Number and the Record Status will correspond 
to the last Update Record EFsms APDU received. 

EVENTJJNFORMA TTED_SMS_PP_UPD 

This event is generated when a Short Message Point to Point (Single or Concatenated) is received by 
Update Record EFsms APDU(s) and is unformatted. 

The SIM Toolkit Framework will first update the EFsms file, convert the received APDU as described 
above, and then trigger all the registered toolkit applets. All of them may modify the content of EFsms 
(i.e. the toolkit applets need to have access to the EFsms file). 

EVENT FORMATTED SMS CB, EVENT UNFORMATTED SMS CB 
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When the ME receives a new cell broadcast message, the cell broadcast page may be passed to the SIM using 
the envelope command according to the content of the EFcbmid file. E.g. the application may then read the 
message and extract a meaningful piece of information which could be displayed to the user, for instance. 

The received cell broadcast page can be either: 

- formatted according to TS 23.048 [4] or an other protocol to identify explicitly the toolkit applet for which 
the message is sent ; 

- unformatted or using a toolkit applet specific protocol the SIM Toolkit Framework will pass this data to all 
registered toolkit applets. 

EVENT_FORMATTED_SMS_CB 

This event is triggered by an envelope APDU containing an CELL_BROADCAST_DATADOWNLOAD 
BER TLV with a Cell Broadcast Page simple TLV according to TS 23.048 [4]. 

The SIM Toolkit Framework shall: 

verify the TS 23.048[4] security of the Cell Broadcast Page; 

trigger the toolkit applet registered with the corresponding TAR defined at applet loading. 

The toolkit applet will only be triggered if the TAR is known and the security verified, application data 
will also be deciphered. 

The TAR value is the same as the one used in the events EVENT_FORMATTED_SMS_PP_ENV and 
EVENT_FORMA TTED_SMS_PP_UPD. 

EVENT_UNFORMATTED_SMS_CB 

The registered toolkit applets will be triggered by this event and get the data transmitted in the APDU 
envelope CELL_BROADCAST_DATADOWNLO AD. 

EVENT_CALL_CONTROL_BY_SIM 

When the SIM is in call control mode and when the user dials a number, this number is passed to the SIM. 
Only one toolkit applet can handle the answer to this command: call barred, modified or accepted. 

EVENT_EVENT_DOWNLOAD_MT_CALL,EVENT_EVENT_DOWNLOAD_CALL_CONNECTED, 

EVENT_EVENT_DOWNLOAD_CALL_DISCONNECTED,EVENT_EVENT_DOWNLOAD_LOCATION_STATUS, 

EVENT_EVENT_DOWNLOAD_USER_ACTIVITY,EVENT_EVENT_DOWNLOAD_IDLE_SCREEN_AVAILABLE, 

EVENT_EVENT_DOWNLOAD_CARD_READER_STATUS, 

EVENT_EVENT_DOWNLOAD_LANGUAGE_SELECTION, 

EVENT_EVENT_DOWNLOAD_BROWSER_TERMINATION,EVENT_EVENT_DOWNLOAD_DATA_AVAILABLE, 

EVENT_EVENT_DOWNLOAD_CHANNEL_STATUS 

The toolkit applet will be triggered by the registered event download trigger, upon reception of the 
corresponding Envelope command. 

In order to allow the toolkit applet to be triggered by these events, the SIM Toolkit Framework shall have 
previously issued a SET UP EVENT LIST proactive command. When a toolkit applet changes one or more of 
these requested events of its registry object, the SIM Toolkit Framework shall dynamically update the event 
list stored in the ME during the current card session. 

EVENT_EVENT_DOWNLOAD_DATA_AVAILABLE,EVENT_EVENT_DOWNLOAD_CHANNEL_STATUS 

For EVENT_EVENT_DOWNLOAD_DATA_AVAILABLE and 

EVENT_EVENT_DOWNLOAD_CHANNEL_STATUS, the framework shall only trigger the applet 
registered to these events with the appropriate channel identifier. 

The registration to the EVENT_EVENT_DOWNLOAD_DATA_AVAILABLE and 
EVENT_EVENT_DOWNLOAD_CHANNEL_STATUS is effective once the toolkit applet has issued a 
successful OPEN CHANNEL proactive command, and vaUd till the first successful CLOSE CHANNEL 
or a channel link is released by the ME or the card session. 

When a Toolkit Applet has sent an OPEN CHANNEL proactive command and received a successful 
TERMINAL RESPONSE, the framework shall register the received channel identifier for the calling 
Toolkit Applet. 
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When a Toolkit Applet has sent a CLOSE CHANNEL proactive command and received a successful 
TERMINAL RESPONSE, the framework shall release the channel identifier contained in the command. 

A successful TERMINAL RESPONSE means that the result of the proactive command execution belongs 
to command performed category (i.e. General Result ='0x'). 

EVENT_MO_SHORT_MESSAGE_CONTROL_BY_SIM 

Before sending an SMS MO entered by the user, the SMS is submitted to the SIM. Only one toolkit applet can 
register to this event 

EVENT_TIMER_EXPIRATION 

At the registration to this event the toolkit applet gets the reference to its timer. The toolkit applet can then 
manage the timer, it will be triggered at the reception of the APDU Envelope TIMER EXPIRATION. 

The SIM Toolkit Framework shall reply busy to this Envelope APDU if it cannot guaranty to trigger the 
corresponding toolkit applet. 

EVENT_UNRECOGNIZED_ENVELOPE 

The applet registered to this event shall be triggered by the framework if the BER-TLV tag contained in the 
ENVELOPE APDU is not defined in the associated release of TS 11 . 14 [3] and if no corresponding constant is 
defined in the list of the ToolkitConstants interface. The unrecognized Envelope event will allow a toolkit 
applet to handle the evolution of the TS 11.14 specification. 

Note: As a consequence of the EnvelopeResponseHandler availability rules specified in clause 6.6, only the 
first triggered toolkit applet is guaranteed to be able to send back a response. 

EVENT_STA TUS_COMMAND 

At reception of a STATUS APDU command, the SIM Toolkit Framework shall trigger the registered toolkit 
applet. 

A range of events is reserved for proprietary usage (from -128 to -1). The use of these events will make the toolkit 
applet incompatible. 

The toolkit applet shall be triggered for the registered events upon reception, and shall be able to access to the data 
associated to the event using the methods provided by the sim.toolkit.ViewHandler.EnvelopeHandler class. 

The order of triggering the toolkit applet shall follow the priority level of each toolkit applet defined at its loading. If 
several toolkit applets have the same priority level, the last loaded toolkit applet takes precedence. 



6.3 Registration 



During it's installation the toolkit applet shall register to the JCRE and the SIM Toolkit Framework so that it can be 
triggered by both selection mechanisms. 

The toolkit applet will have to call the getEntryO method to get a reference to it's registry and then to explicitly register 
to each event it requires. 

The toolkit applet can change the events to which it is registered during its life cycle. 

The toolkit applet will dynamically register itself to some event e.g. EVENT _MENU_SELECTION by calling the 
corresponding method e.g. initMenuEntry(). 

The API is described in the sim.toolkit.ToolkitRegistry class in Annex A. 



6.4 Proactive command handling 



The SIM application toolkit protocol (i.e. 91xx, Fetch, Terminal Response) is handled by the GSM applet and the 
Toolkit Handler, the toolkit applet shall not handle those events. 
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The SIM Toolkit Framework shall provide a reference of the sim.toolkit.ViewHandler.EditHandler.ProactiveHandler to 
the toolkit applet so that when the toolkit applet is triggered it can : 

initialise the current proactive command with the init() method ; 

append several Simple TLV as defined in TS 1 1.14 [3] to the current proactive command with the appendTLVQ 
methods ; 

ask the SIM Toolkit Framework to send this proactive command to the ME and wait for the reply, with the 
send() method. 

The GSM applet and the SIM Toolkit Framework shall handle the transmission of the proactive command to the ME, 
and the reception of the response. The SIM Toolkit Framework will then return in the toolkit applet just after the send() 
method. It shall then provide to the toolkit applet the sim.toolkit.ViewHandler.ProactiveResponseHandler, so that the 
toolkit applet can analyse the response. 

The proactive command is sent to the ME as defined and constructed by the toolkit applet without any check of the SIM 
Toolkit Framework. 

The SIM Toolkit Framework shall prevent the toolkit applet to issue the following proactive commands: SET UP 
MENU, SET UP EVENT LIST, POLL INTERVAL, POLLING OFF. If an applet attempts to issue such a command, 
the SIM Toolkit Framework shall throw an exception. 

The SIM Toolkit Framework shall prevent a toolkit applet to issue a TIMER MANAGEMENT proactive command 
using a timer identifier, which is not allocated to it. If an applet attempts to issue such a command, the SIM Toolkit 
Framework shall throw an exception. 

The SIM Toolkit Framework shall prevent a toolkit applet to issue a SEND DATA, RECEIVE DATA and CLOSE 
CHANNEL proactive commands using a channel identifier, which is not allocated to it. If an applet attempts to issue 
such a command the SIM Toolkit Framework shall throw an exception. 

The SIM Toolkit Framework shall prevent a toolkit applet to issue an OPEN CHANNEL proactive command if it 
exceeds the maximum number of channel allocated to this applet. If an applet attempts to issue such a command the 
SIM Toolkit Framework shall throw an exception. 

The SIM Toolkit Framework cannot guarantee that if the SET UP IDLE MODE TEXT proactive command is used by a 
toolkit applet, another toolkit applet will not overwrite this text at a later stage. 



6.5 Envelope response handling 



To allow a toolkit applet to answer to some specific events (e.g. EVENT_CALL_CONTROL_BY_SIM) the SIM 
Toolkit Framework shall provide the sim.toolkit.ViewHandler.EditHandler.EnvelopeResponseHandler. 

The toolkit applet can then post a response to some events with the post() or the postAsBEKTLV() methods, the toolkit 
applet can continue it's processing (e.g. prepare a proactive command) the SIM Toolkit Framework will return the 
response APDU defined by the toolkit applet (i.e. 9F xx, 9E xx or 91 xx). 

Case of EVENT_FORMATTED_SMS_PP_ENV: 

When the post() or the postAsBERTLV() method is invoked, the SIM Toolkit Framework shall, according to bit 6 of the 
second octet of the SPI defined in TS 23.048[4], build a SMS-DELIVER-REPORT or a SMS-SUBMIT. In case of 
SMS-SUBMIT the statusType method parameter is meaningless. If the SMS-SUBMIT is to be used, the SIM Toolkit 
Framework shall build and issue a Send Short Message proactive command as defined in TS 11.14 [3]. 



6.6 Handler availability 



The system handlers: ProactiveHandler, ProactiveResponseHandler, EnvelopeHandler and EnvelopeResponseHandler 
are Temporary JCRE Entry Point Object as defined in the Java Card Runtime Environment Specification [8]. 

The following rules define the minimum requirement for the availability of the system handlers and the lifetime of their 
content. They are generic rules and may vary with the event that triggers the toolkit applet. 
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ProactiveHandler: 

The ProactiveHandler is valid from the invocation to the termination of the processToolkit method. 

If a proactive command is pending the ProactiveHandler may not be available. 

At the processToolkit method invocation the TLV-List is cleared. 

At the call of it's init method the content is cleared and then initialised. 

After a call to ProactiveHandler. send method the handler will remain unchanged (i.e. previously send proactive 
command) until the ProactiveHandler.init or appendTLV methods are called. 

ProactiveResponseHandler: 

The ProactiveResponseHandler may not be available before the first call to ProactiveHandler.send method, if 
available the content is cleared. 

The ProactiveResponseHandler is available after the first call to the ProactiveHandler.send method to the 
termination of the processToolkit method. 

If a proactive command is pending the ProactiveResponseHandler may not be available. 

The ProactiveResponseHandler content is changed after the call to ProactiveHandler.send method and remains 
unchanged until next call to the ProactiveHandler.send method. 

EnvelopeHandler: 

The EnvelopeHandler and its content are available for all triggered toolkit applets (see Table 1), from the 
invocation to the termination of their processToolkit method. 

The SIM Toolkit Framework guarantees that all registered toolkit applet are triggered and receive the data. 

EnvelopeResponseHandler: 

The EnvelopeResponseHandler is available for all triggered toolkit applets, until a toolkit applet has posted an 
envelope response or sent a proactive command. After a call to the post method the handler is no longer 
available. 

At the process Toolkit method invocation the TLV-List is cleared. 

The EnvelopeResponseHandler content must be posted before the first invocation of a ProactiveHandler.send 
method or before the termination of the processToolkit, so that the GSM applet can offer these data to the ME 
(eg 9Fxx/9Exx/91xx). After the first invocation of the ProactiveHandler.send method the 
EnvelopeResponseHandler is no more available 

The following diagram illustrates these rules. 
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Figure 5: Typical handler availability for toolkit applets (see Table 1 for detail) 

The following table describes the minimum availability of the handlers for all the events at the invocation of the 
processToolkit method of the toolkit applet. 
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Table 1 : Handler availability for eachi event 



EVENT_ 


Reply 

busy 

allowed 


Envelop 
eHandler 


EnvelopeRes 
ponseHandler 


Nb of triggered 

/ registrered 

Applet 


_F0RI\/1ATTED_SMS_PP_ENV 


Y 
(see Note 2) 


Y 


Y 


1 / n (per TAR) 


FORMATTED SMS PP UPD 


N 


Y 


N 


1 / n (per TAR) 


UNFORMATTED SMS PP ENV 


Y 


Y 


Y 


n / n 


UNFORMATTED SMS PP UPD 


N 


Y 


N 


n/n 


FORMATTED SMS CB 


Y 


Y 


N 


1/n(perTAR) 


UNFORMATTED SMS CB 


Y 


Y 


N 


n/n 


MENU SELECTION 


Y 


Y 


N 


1 / n (per Item Id) 


MENU SELECTION HELP REQUES 

T 


Y 


Y 


N 


1 / n (per Item Id) 


CALL CONTROL 


N 


Y 


Y 


1 /1 


SMS MO CONTROL 


N 


Y 


Y 


1 /1 


_TIMER_EXPIRATION 


Y 


Y 


N 


1/8 (per timer) 
(see Note 1 ) 


EVENT DOWNLOAD 










MT CALL 


Y 


Y 


N 


n/n 


CALL CONNECTED 


Y 


Y 


N 


n/n 


CALL DISCONNECTED 


Y 


Y 


N 


n / n 


LOCATION STATUS 


Y 


Y 


N 


n/ n 


USER ACTIVITY 


Y 


Y 


N 


n/n 


IDLE SCREEN AVAILABLE 


Y 


Y 


N 


n / n 


CARD READER STATUS 


Y 


Y 


N 


n/n 


LANGUAGE SELECTION 


Y 


Y 


N 


n/n 


BROWSER TERMINATION 


Y 


Y 


N 


n/n 


_DATA_AVAILABLE 


Y 


Y 


N 


1/7 (per channel) 
(see Note 1 ) 


_CHANNEL_STATUS 


Y 


Y 


N 


1/7 (per channel) 
(see Note 1 ) 


UNRECOGNIZED ENVELOPE 


Y 


Y 


Y 


n/n 


STATUS COMMAND 


N 


N 


N 


n/ n 


PROFILE DOWNLOAD 


N 


N 


N 


n / n 


FIRST COMMAND AFTER SELECT 


N 


N 


N 


n/n 


Note 1 : One toolkit applet can register to several timers/channels, but a timer/channel can 
only be allocated to one toolkit applet. 

Note 2: The framework may reply busy and not trigger the toolkit applet if a PoR using 
SMS SUBMIT is required in the incoming message and a proactive session is 
ongoing. 



6.7 SIM Toolkit Framework behaviour 

The following rules define the SIM Toolkit Framework behaviour for : 

Triggering of a toolkit applet (invocation of the processToolkit() method from the Toolkitlnterface shareable 
interface) : 

The current context is switched to the toolkit applet . 

A pending transaction is aborted. 

There is no invocation of the selectQ or the deselect() methods. 

The CLEAR_ON_DESELECT transient object can not be accessed and not created as defined in Java Card 
2.1 Runtime Environment Specification [8], as the current selected application is unchanged (eg GSM applet) 
and does not correspond to the current context which is the toolkit applet. 

The current file context of the toolkit applet is the MF. 

The current file context of the current selected applet is unchanged. 

The toolkit applet cannot access the APDU object. 
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Termination of a toolkit applet (return from the processToolkit() method): 

The JCRE switches back to the context of the current selected applet, the GSM applet. 

There is no invocation of the selectQ or the deselect() methods. 

A pending toolkit applet transaction is aborted. 

The transient data are unchanged. 

The current file context of the toolkit applet is lost. 

The current file context of the current selected applet is unchanged. 

The GSM applet shall not rely on the APDU object content. The APDU content may be changed by the 
system [For Further Study as the interface between the toolkit system and the GSM applet is not defined yet] 

Invocation of ProactiveHandler.send() method : 

During the execution there might be other context switches, but at the return of the send() method the toolkit 
applet context is restored. 

There is no invocation of the selectQ or the deselect() methods. 

A pending toolkit applet transaction at the method invocation is aborted. 

The current file context of the toolkit applet is unchanged (see chapter 5.2). The send() method will never 
return if the GSM applet is deselected and another applet is explicitly selected. 

Emission of system proactive commands (SIM Toolkit framework dynamic behaviour) 

The SIM Toolkit Framework shall send its system proactive command as soon as no proactive session is 
pending and all the applets registered to the current events have been triggered and have returned from the 
processToolkit method invocation. 

6.8 Usage of ViewHandler and EditHandler 

The ViewHandler and EditHandler classes have been defined to group the properties of the system handler, and may be 
used in the future to provide a simple mechanism to the toolkit applet to handle TLV lists. The length of simple TLV 
present in a Handler TLV List shall be coded according to ISO/IEC 7816-6 [12] (e.g. coded onto l,or 2 or 3 bytes). 



7 SIM toolkit applet 

7.1 Applet Loading 

The SIM API card shall be compliant to the Java Card 2. 1 VM Architecture Specification [9] and to the Annex B to 
guarantee interoperability at byte code Level. 

The applet loading mechanism, protocol and applet life cycle are defined in TS 23.048 [4] 



7.2 Object Sharing 



The sharing mechanism defined in Java Card 2.1 API Specification [7] and Java Card 2.1 Runtime Environment 
Specification [8] shall be used by the applet to share data. 

The byte parameter of the getShareableInterfaceObject() method shall be set to zero (i.e. '00') when the Toolkitlnterface 
reference is required. 
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Annex A (normative): 
Java Card SIM API 



The attached files "Annex_Ajava.zip" and "Annex_A_HTML.zip" contains source files for the Java Card SIM API. 
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Annex B (normative): 

Java Card SIM API identifiers 



The attached file "Annex_B_Export_files.zip" contains source files for the Java Card SIM API identifiers. 

NOTE: The export files in this annex have been generated with the following steps and tools : 

Compilation from the API Java source file (.Java) to the API class files (.class) with the Java 
compiler from the Java Development Kit version 1.2.2. 

Convertion from the API class files (.class) to the API export files (.exp) with the Java Card 2.1.2 
Class File Converter (version 1 .2) and the Java Development Kit 1 .2.2. 
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Annex C (normative): 

SIM API package version management 

The following table describes the relationship between each TS 03.19 / TS 43.019 specification version and its SIM API 
packages AID and Major, Minor versions defined in the export files. 



TS 03.19 
/ 43.019 
version 


sim.access package 


sim.toolkit package 


AID 


Major, 
Minor 


AID 


Major, 
Minor 


7.0.0 


A000000009 0003FFFFFFFF89 1 070000 1 


1.0 


A000000009 0003FFFFFFFF89 1 0700002 


1.0 


7.1.0 


A000000009 0003FFFFFFFF89 1 07 1 000 1 


2.0 


A000000009 0003FFFFFFFF89 1 07 1 0002 


2.0 


7.2.0 


A000000009 0003FFFFFFFF89 1 07 1 000 1 


2.0 


A000000009 0003FFFFFFFF89 1 07 1 0002 


2.0 


7.3.0 


A000000009 0003FFFFFFFF89 1 07 1 000 1 


2.0 


A000000009 0003FFFFFFFF89 1 07 1 0002 


2.0 


7.4.0 


A000000009 0003FFFFFFFF89 1 07 1 000 1 


2.1 


A000000009 0003FFFFFFFF89 1 07 1 0002 


2.1 


7.5.0 


A000000009 0003FFFFFFFF89 1 07 1 000 1 


2.1 


A000000009 0003FFFFFFFF89 1 07 1 0002 


2.1 


8.0.0 


A000000009 0003FFFFFFFF89 1 07 1 000 1 


2.2 


A000000009 0003FFFFFFFF89 1 07 1 0002 


2.2 


8.1.0 


A000000009 0003FFFFFFFF89 1 07 1 000 1 


2.2 


A000000009 0003FFFFFFFF89 1 07 1 0002 


2.2 


8.2.0 


A000000009 0003FFFFFFFF89 1 07 1 000 1 


2.2 


A000000009 0003FFFFFFFF89 1 07 1 0002 


2.2 


8.3.0 


A000000009 0003FFFFFFFF89 1 07 1 000 1 


2.2 


A000000009 0003FFFFFFFF89 1 07 1 0002 


2.2 


8.4.0 


A000000009 0003FFFFFFFF89 1 07 1 000 1 


2.2 


A000000009 0003FFFFFFFF89 1 07 1 0002 


2.2 


8.4.1 


A000000009 0003FFFFFFFF89 1 07 1 000 1 


2.2 


A000000009 0003FFFFFFFF89 1 07 1 0002 


2.2 


8.5.0 


A000000009 0003FFFFFFFF89 1 07 1 000 1 


2.2 


A000000009 0003FFFFFFFF89 1 07 1 0002 


2.2 


4.0.0 


A000000009 0003FFFFFFFF89 1 07 1 000 1 


2.2 


A000000009 0003FFFFFFFF89 1 07 1 0002 


2.2 


4.1.0 


A000000009 0003FFFFFFFF89 1 07 1 000 1 


2.2 


A000000009 0003FFFFFFFF89 1 07 1 0002 


2.2 


4.2.0 


A000000009 0003FFFFFFFF89 1 07 1 000 1 


2.2 


A000000009 0003FFFFFFFF89 1 07 1 0002 


2.2 


4.3.0 


A000000009 0003FFFFFFFF89 1 07 1 000 1 


2.2 


A000000009 0003FFFFFFFF89 1 07 1 0002 


2.2 


5.0.0 


A000000009 0003FFFFFFFF89 1 07 1 000 1 


2.2 


A000000009 0003FFFFFFFF89 1 07 1 0002 


2.3 


5.0.1 


A000000009 0003FFFFFFFF89 1 07 1 000 1 


2.2 


A000000009 0003FFFFFFFF89 1 07 1 0002 


2.3 


5.1.0 


A000000009 0003FFFFFFFF89 1 07 1 000 1 


2.2 


A000000009 0003FFFFFFFF89 1 07 1 0002 


2.4 


5.2.0 


A000000009 0003FFFFFFFF89 1 07 1 000 1 


2.2 


A000000009 0003FFFFFFFF89 1 07 1 0002 


2.5 


5.3.0 


A000000009 0003FFFFFFFF89 1 07 1 000 1 


2.2 


A000000009 0003FFFFFFFF89 1 07 1 0002 


2.6 


5.4.0 


A000000009 0003FFFFFFFF89 1 07 1 000 1 


2.2 


A000000009 0003FFFFFFFF89 1 07 1 0002 


2.6 


5.5.0 


A000000009 0003FFFFFFFF89 1 07 1 000 1 


2.2 


A000000009 0003FFFFFFFF89 1 07 1 0002 


2.6 



The package AID coding is defined in TS 101 220 [10]. The SIM API packages' AID are not modified by changes to 
Major or Minor Version. 
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The Major Version shall be incremented if a change to the specification introduces byte code incompatibility with the 
previous version. 

The Minor Version shall be incremented if a change to the specification does not introduce byte code incompatibility 
with the previous version. 
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Annex D (informative): 
Toolkit applet example 

The attached file "Annex_D_ToolkitAppletExample.zip" contains source files for the toolkit applet example. 



£75/ 



3GPP TS 43.019 version 5.5.0 Release 5 



24 



ETSI TS 143 019 V5.5.0 (2002-12) 



Annex E (informative): 
Change history 



The table below indicates all change requests that have been incorporated into the present document. 



Change history 


Date 


TSG# 


TSG Doc 


CR 


Re 

V 


Cat 


Subject/Comment 


Old 


New 


2001-06 


TP-12 










TS 43.019 version 4.0.0 created from TS 03.19 version 
8.2.0. No technical changes were introduced 




4.0.0 


TP-010102 


A013 




c 


Limitation of proactive command issued by an 
application 


4.0.0 
5.0.0 


5.0.0 
5.0.1 


A015 




B 


Integrate the Bearer Independent Protocol Feature 
defined release 99 










Re-issued to correct errors introduced in the production 
of the library in Annex B in v 5.0.0. 


2001-12 


TP-14 


TP-010241 


001 




F 


API methods and Framework behaviour clarifications 
regarding ProactiveHandler and 
EnvelopeResponseHandler 


5.0.1 


5.1.0 


002 




D 


Editorial corrections of constant name 


003 




B 


Addition of the EVENT FIRST COMMAND 
AFTER SELECT as a toolkit event 


004 




C 


Extension of list of Simple BER TLV tags in 
Sim .toolkit.ToolkitConstants 


005 




C 


ToolkitRegistry methods modification 


006 




C 


ToolkitRegistry methods modification when no TAR is 
defined 


007 




C 


Applet triggering on Menu Help Request event 


009 




A 


Clarification of ToolkitException. 

OUT OF TLV BOUNDARIES in ViewHandler.java 


2002-03 


TP-15 


TP-020073 


010 




F 


SET-UP-MENU command issued if all the items 
supporting help are disabled 


5.1.0 


5.2.0 


Oil 




B 


Indication of the handler size to the applet 


012 




F 


Clarification on framework behaviour for PoR using SMS 
SUBMIT 


014 




B 


Change in the EnvelopeResponseHandler behaviour 


015 




C 


Handler availability 


2002-06 


TP-16 


TP-020120 


013 




B 


Introduction of Concatenated Short Messages in SMS 
Point to Point 


5.2.0 


5.3.0 


017 




F 


Clarification of MEProfile behaviour 


018 




F 


Approved CRs not correct integrated in the current 
version 


020 




F 


Correction of getSecuredDataOffset() method 
description for SMS-CB. 


2002-09 


TP-17 


TP-020217 


021 




F 


Clarification of 

ToolkitException.HANDLER_NOT_AVAILABLEfor 
getCapacityO methods 


5.3.0 


5.4.0 


022 




F 


Clarification on 

EVENT FIRST COMMAND Ah 1 ER SELECT 


023 




F 


Specification alignment with approved change requests 


025 




F 


Correction of method getChannelldentifier() 


026 




F 


Clarification of handling of statusType parameter by the 
framework in case of PoR. 


027 




F 


Correction of the example applet 


2002-12 


TP-18 


TP-020283 


028 




F 


Clarification of several methods regarding APDU 
overflow 


5.4.0 


5.5.0 


029 




F 


Availability of Proactivehandler and 
ProactiveResponseHandler for 
EVENT_FIRST_COMMAND_AFTER_SELECT 
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